Danny/connect docs source logs #16559
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
## Walkthrough
The documentation for Pipedream Connect components was updated to include a new "Troubleshooting" section. This section details common issues, such as referencing the correct app prop name and handling dynamic props, and provides guidance on viewing source logs for deployed triggers, including descriptions of the sources UI and its current limitations. Additionally, the workflows documentation was enhanced to clarify authentication contexts, specifying OAuth client requirements for end user workflows and adding an informational callout about authentication scopes in HTTP webhook triggers. Several other Connect docs were revised to replace references to contacting Sales with links to the pricing page for production access and updated pricing details.
## Changes
| File(s) | Change Summary |
|-----------------------------------------|------------------------------------------------------------------------------------------------------------------------------------|
| docs-v2/pages/connect/components.mdx | Added a "Troubleshooting" section covering app prop naming, dynamic props handling, and instructions for checking source logs. |
| docs-v2/pages/connect/workflows.mdx | Clarified authentication contexts and OAuth client usage for end user workflows; added an OAuth client requirements section and an informational callout under HTTP webhook trigger. Minor formatting adjustments made. |
| docs-v2/pages/connect/environments.mdx | Replaced instructions to contact Sales for production access with guidance to visit the pricing page. |
| docs-v2/pages/connect/index.mdx | Updated "Plans and pricing" section to clarify Connect is free to start in development and linked to updated pricing page. |
| docs-v2/pages/connect/mcp.mdx | Revised MCP server deployment instructions to remove Sales contact step, add free development mode usage, and link to pricing page for production. |
## Suggested reviewers
- adolfo-pd
## Poem
> 🐇
> When docs grow wise with troubleshooting tips,
> Bugs and errors take their final dips.
> With camelCase names and dynamic IDs in tow,
> Debugging becomes a gentle flow.
> Now logs and tabs are easy to see—
> Oh, what a happy dev rabbit I’ll be!Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
docs-v2/pages/connect/components.mdx (3)
1016-1035: Grammar and clarity improvements for app prop reference.
- Change the sentence
to use “as returned by” which reads more idiomatically.- Always use the exact app prop name that's returned in the component definition. + Always use the exact app prop name as returned by the component definition.- Explicitly note that this must match the camelCase
namefield underconfigurable_propsin the component’s JSON (not thekeyorappslug).🧰 Tools
🪛 LanguageTool
[grammar] ~1022-~1022: The usual collocation for “returned” is “to”, not “in”.
Context: ...ways use the exact app prop name that's returned in the component definition. The app prop...(RETURN_IN_THE)
1037-1091: Enhance the dynamic props ID guidance.
- Wrap code examples in proper triple backticks with the
javascripttag for consistency.- Emphasize persisting
dynamicProps.idin your application state before invoking actions.- Provide an MDX link back to the “Configure dynamic props” section, e.g.:
[Configure dynamic props](#configure-dynamic-props)- Example refactor:
// Reload dynamic props const { dynamicProps } = await pd.reloadProps({ … }); // Persist dynamicProps.id, then: const resp = await pd.runAction({ externalUserId: "abc-123", id: "google_sheets-add-single-row", dynamicPropsId: dynamicProps.id, // Must include this configuredProps: { … } });
1092-1113: Format source logs URL and unify placeholder naming.
- Wrap the URL in triple backticks for better readability:
https://pipedream.com/sources/{sourceId}- Rename
{dcid}to{sourceId}or{deployedTrigger.id}to mirror variable names used earlier.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (1)
docs-v2/pages/connect/components.mdx(1 hunks)
🧰 Additional context used
🪛 LanguageTool
docs-v2/pages/connect/components.mdx
[grammar] ~1022-~1022: The usual collocation for “returned” is “to”, not “in”.
Context: ...ways use the exact app prop name that's returned in the component definition. The app prop...
(RETURN_IN_THE)
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: pnpm publish
- GitHub Check: Lint Code Base
- GitHub Check: validate-links
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
docs-v2/pages/connect/workflows.mdx (1)
419-420: Simplify wording for readability
Consider replacing “Anyone is able to run workflows…” with “Anyone can run workflows…” to make the text more concise:- Anyone is able to run workflows for your end users in `development`. + Anyone can run workflows for your end users in `development`.🧰 Tools
🪛 LanguageTool
[style] ~419-~419: As a shorter alternative for ‘able to’, consider using “can”.
Context: ...on requires a higher tier plan - Anyone is able to run workflows for your end users in `de...(BE_ABLE_TO)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
docs-v2/pages/connect/environments.mdx(2 hunks)docs-v2/pages/connect/index.mdx(1 hunks)docs-v2/pages/connect/mcp.mdx(1 hunks)docs-v2/pages/connect/workflows.mdx(4 hunks)
✅ Files skipped from review due to trivial changes (2)
- docs-v2/pages/connect/index.mdx
- docs-v2/pages/connect/environments.mdx
🧰 Additional context used
🪛 LanguageTool
docs-v2/pages/connect/workflows.mdx
[style] ~419-~419: As a shorter alternative for ‘able to’, consider using “can”.
Context: ...on requires a higher tier plan - Anyone is able to run workflows for your end users in `de...
(BE_ABLE_TO)
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: pnpm publish
- GitHub Check: Lint Code Base
- GitHub Check: validate-links
🔇 Additional comments (4)
docs-v2/pages/connect/mcp.mdx (1)
181-182: Consistent pricing update
The new bullets correctly remove the “contact Sales” requirement and direct users to the pricing page for production, matching the updates in other Connect docs.docs-v2/pages/connect/workflows.mdx (3)
268-270: Clarify authentication context
The added callout clearly distinguishes Pipedream API authentication from managed auth for end users, which helps avoid confusion when securing HTTP webhooks.
274-274: Approve explicit credential bullet
Specifying that the OAuth client ID and secret apply to Pipedream API authentication reinforces the preceding callout and ensures developers know which credentials to use.
369-379: Great addition of OAuth client requirements
This new section succinctly outlines why custom OAuth clients are required for end-user workflows and provides concrete steps and links. It significantly improves the guidance for developers integrating Connect features.
WHY
Summary by CodeRabbit